REMARKS 

Parti 



Reconsideration of this application (number 10/057151) and withdrawal of the final rejections set forth 
in the office action mailed January 1 8, 2007 are requested in view of these following remarks. 

Remarks regarding the First argument made by the examiner. 

Regarding the rejection of 
Abdolsalehi Claim 7 

Refuting examiner's argument (Scuderi) in relation to "bandwidth error." 

This claim should not be rejected based on the fact that bandwidth does in fact scientifically limit the quality 
and amount of bandwidth necessary to view a broadcast transmission over the Internet, resulting in a measured 
bandwidth error. 

The error in bandwidth is in reference to an insufficient calculation and supply of internet bandwidth to supply 
audio and or video, or as the viewer is concerned, it is an insufficient calculation and supply of internet 
bandwidth to receive and interact with the source audio and or video. 

An error in bandwidth calculation based on an assumed audience number of audience resource, will determine 
the rate at which the stream will deteriorate. 

The more severe this error becomes, the further increased the rate of deterioration will be, based on the number 
of attendees. 

And so if there are no users, there will be no error. 

Therefore, the claim does in fact particularly point out and distinctly teach the subject matter which I regard as 
the invention. 

(with reference to 35 U.S.C. 112). 



Reconsideration of this application (number 10/057151) and withdrawal of the final rejections set forth 
in the office action mailed January 18, 2007 are requested in view of these following remarks. 

Remarks regarding the Second argument made by the examiner: 

Regarding the rejection of 
Abdolsalehi Claims 1,3-5, 7. 

These claim should not be rejected based on the unique differences of my teachings from Davies. 
Davies does not teach 

Transmission of solely one-way video and two-way audio over a publicly accessible Internet Video and Voice 
over IP. 
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In my teachings, 

The Video and Voice over IP will serve as a point at which a professional quality one-way video broadcast and 
a separate two-way audio channel can be streamed and then pinged from a user's or multiple users' 
computer(s). 

This will allow better broadcast transmittal, meaning the utilization of broadcast quality codecs, which by the 
lowest standards is regular TV broadcast quality which is still far more superior to video conferencing quality. 

My technology allows multiple users with access to the Internet to gain access to data streams. 

There is no mention or presence of computer servers as the root and origination of video/audio presentations in 
any of Davies claims. 

My invention teaches sending solely a one way video absent of an audio channel combined with a separate two 
way audio channel within a single GUI on a webpage. 

These components combined establish a completely different motive and lesson from what Davies teaches. 

If you copy entries E and F from claim 2 into claim 1, it will shed more light onto the function and the role that 
the webpage plays along with how it differentiates from Davies and Lee. 

Review of Claims made my Davies as they Differ from Abdolsalehi 

Davies claims 2, 3. 

Davies teaches that he has a synch occurring with data prior to leaving the gateway, 

I teach that synch occurs on the users system after he loads the combined technology webpage. 

Davies claims 5, 6. 

Davies teaches that he loops back his signals in 6, and has a steam mismatch detector prior to exiting his 
Gateway in 5... 

In my teachings this form or error check cannot occur in the system that I have developed for it would 
add to delay and would not be possible through the users end webpage presentation. My streams are in two 
separate parts synched by the user. 

Davies claim 7. 

Davies teaches that he has device transmission delays which are stored at his gateway, 

My system has no storable delay for it is a real time solution, irrelevant of a gateway and presented on 
the users system where transmission delays are then calculated. 

Davies claim 8. 

Davies teaches that his gateway determines relative time difference, 

Whereas time difference on my system is determined by the user system on the loading webpage. 

Davies claim 9. 

Davies teaches that his gateway is calibrated, 

Whereas I teach that my gateway is standard, where the users system is designated with the task of 
calibration. 

Davies claims 13, 15, 16, and 12. 

Davies teaches a method of transmission where multiple devices are required in 13. 

I teach a method where different components can be broadcasted separately but on one machine if 
needed. 




Davies furthers explains the storage of delay, in 13; looping back of delay through his gateway in 14; additional 
test signals in 15; and sensory output delays in 16, and physical adjustment of delay in 12... 

What I teach has no storage or physical adjustment of delay, for transmission components are later 
calculated and expunged naturally since the presentation open in a single GUI on a webpage on the users end. 

Additional test signals will also add to buffering time, and then add to delay, which defeats the purpose 
of what teach (separating the audio component from the video broadcast, so to take advantage of higher frame 
rates and lower delays). 

This is also true of the incorporated sensory output delays that Davies teaches. 
Davies claim 17. 

Davies teaches a system where his Gateway is set to determine delay... 

Whereas in my teachings the gateway has no such role, instead the users system, based on the webpage 
that shows all the components, determines the delay. 

Davies claim 18. 

Davies teaches a system where his network gateway is calibrated and determining, 

In my teachings, no such modification is made as the broadcasts occur over and Internet based Video 
and Voice over IP and the calibration point occurs on the users system when the webpage containing the content 
loads. 



Therefore, I am entitled to a patent, for my combined teachings have not been published in any other patent 
publication in the United States and Internationally, 
(with reference to 35 U.S.C. 102). 



Reconsideration of this application (number 10/057151) and withdrawal of the final rejections set forth 
in the office action mailed January 18, 2007 are requested in view of these following remarks. 

Remarks regarding the Third argument made by the examiner. 

Regarding the rejection of 
Abdolsalehi Claims 2, 6. 

These claims should not be rejected based on the teachings of Davies in view of Lee 
for the following reasons: 

There exists an ample amount of information present in my claims to prove that the webpage in question is far 
from ordinary. 

If you copy entries E and F from claim 2 into claim 1, it will shed more light onto the function and the role that 
the webpage plays along with how it differentiates from Davies and Lee. 

My webpage is the point where the broadcast and the audio chat are integrated into one accessible body. Thus 
enabling the user to seamlessly communicate with the broadcast. 
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This is far from common use of a webpage. The function is not ordinary, and it is not designed to simply play 
video or audio, it is designed to integrate all the data streams into one point, and have the users systems synch 
and access data that would be of instant use for real time communication and broadcast viewing. 

In addition Davies at best teaches 

Davies patent is designed for video conferencing one on one, utilizing a video device and an audio device like a 
telephone. 

As where I teach an interactive broadcast from one point to many. 

It is not business compatible for click and use for the masses, and both parties need a device setup that is 
inherently not mass internet compatible. 

There is an obvious motivation to combine the two-way audio component, and the solely one way video 
component absent of an audio channel within a single GUI on a web page. 

As Video and Voice over IP is accessible by instant load formats such as Active-x, and/or JavaScript, the GUI 
on the webpage must be present in order to synch the one way video and separate two way audio channels 
together. 

Synch also takes places on this page on the user's machine. Davies teaches synch as taking place on the 
gateway. 

This method that I teach is what makes this technology possible and unique. It enables the technology to be 
absent of a dedicated software shell and instead become Internet Video and Voice over IP compatible. 

In further analyzing the motivation to combine, we see that a few components of Lee and Davies must come 
together to create something new, in this case it is my technology. 

Therefore it is not so obvious to utilize a webpage in the manner in which I have taught, 
(with reference to 35 U.S.C. 103). 

A Brief BACKGROUND of the TECHNOLOGY as it relates to patent application 10/057151 

Current video conferencing software like windows net-meeting firstly relies on the bandwidth of the individual 

users for its audio/video conference, which is usually limited to a DSL line. 

Also the purpose of such software is for one on one, or multiple one on one conferences. 

The software works via a large download and a through and time consuming install where then the two parties 
meet on a common server and conference. 

To compensate for the lack of available bandwidth, the codec in such software is designed to deliver fewer 
frames of audio and video per second between parties. It is not designed for a broadcast, especially a 
professional broadcast to more than one viewer. 

Therefore different software ware created for the purpose. 

In following the Microsoft example, 

Recognizing that the quality and performance of video conferencing is low, and is not designed for a 
professional (high quality or higher frame rate) broadcast. 




Better codecs and software were designed. 
Microsoft's windows media producer . . . 

Can create a broadcast quality live video stream that can be created locally and broadcasted over inter/intranet. 
In utilizing an off the shelf codec or video/audio production software like 

However, when the software is set to also collect and stream audio components out over the web along with the 
video stream, the packet sizes of data is also larger, thus making the stream difficult to view due to a higher 
period of buffering and network delays on the side of both the producer and the viewers. 

Also to get the full experience of the broadcast, the feed is limited by it weakest link in terms of bandwidth, 
which is usually the viewer. 

In trying to get out the best feed possible, the software will account for delay an pre-buffer the audio video 
stream which will further place the source of information into the past. In essence it is a delayed live broadcast. 

Thus dual broadcasts are not practical, for the conference would not be real time, and the time delays would 
double. 

Also both parties would need a professional setup along with a large backing of bandwidth. 

Not to mention that the viewers would need to install software and the conference would be only limited to one 
on one. 

And it would not be business compatible for there is no click and interact option with this setup. 

The objective is to have a business application where the common user can click on a link have a "smart and 
quick install" take place via something like JavaScript or Active-x, and view a broadcast quality feed while 
being able to conference with its source. 

The trick is to have the viewer watch a video only broadcast utilizing the broadcast quality codecs and the large 
broadband connection, while having a simultaneous real-time audio chat codec running simultaneously like a 
HearMe chat. 

Both streams can be accessed on demand by the viewer due to the fact that he does not need any massive 
software, time consuming install, static IP or large bandwidth backing. 

The streams can then also be viewed by many and everyone can interact with the source through moderation. 



In view of the forgoing clarifications, rebuttals and remarks, 

I respectfully resubmit my claims and teachings with regards to patent application 10/057151 for consideration 
and approval. 

Respepffiilly submitted, 



CONCLUSION 




Xli Abdolsalehi 
Inventor 




